Microcontrollers have to provide real time response to events in the embedded system they are controlling. When certain events occur, an interrupt system can signal the processor to suspend processing the current instruction sequence and to begin an interrupt service routine (ISR), also called “interrupt handler”. The ISR will perform any processing required by the interrupt request (IRQ) issued by the source of the interrupt before returning to the original instruction sequence. Possible interrupt sources are device dependent, and often include events such as an internal timer overflow, completing an analog to digital conversion, a logic level change on an input such as from a button being pressed, and data received on a communication link. Where power consumption is important as in battery operated devices, interrupts may also wake a microcontroller from a low power sleep state where the processor is halted until it is required to do something by a peripheral event.
An interrupt controller is designed to provide interrupt capabilities to the main processor (central processing unit, CPU). When a device issues an interrupt request, it is delivered to the interrupt controller, from there the interrupt is generated in the CPU, which, in turn, checks with the interrupt controller for the source of the interrupt through a special register which are being hold at and managed by the interrupt controller.
An interrupt bus provides means by which a device that can generate an interrupt or service request is connected to a device that can service the interrupt. This may usually be an interrupt controller connected to a processor. Each device which can generate an interrupt, a so-called “interrupt source”, such as a Universal Asynchronous Receiver Transmitter (UART) or a timer, has one or more service request nodes (SRNs) that connect directly onto the interrupt bus. It is noted that throughout the application the term “service request node” is used for a node connected to an interrupt bus and interrupt controller, respectively, wherein the service request node is assigned to a specific interrupt source, i.e. a device which can generate an interrupt. Accordingly, the service request node may be connected to or be part of the specific interrupt source.
A system may implement any number of interrupt busses. Each SRN may be configured in software to connect to one of a plurality of interrupt buses (depending on the implementation), or not connect to any interrupt bus. Each interrupt bus is controlled by an interrupt control unit (ICU), connected to SRNs.
An arbitration process for establishing the highest priority service request of a plurality of service requests is performed over the interrupt bus between the ICU and the SRNs. The ICU's processor can optionally accept this service request and generate an interrupt. It may also choose not to accept the service request if it currently servicing a higher priority service request.
Each SRN is assigned a service request priority number (SRPN) by the software running on the system, wherein each SRN that is participating in an arbitration over an interrupt bus requires a unique SRPN. However, two SRNs may share the same SRPN so long as they are using different interrupt busses.
Further, each SRN is also configurable with respect to the interrupt bus/ICU to which it transmits a service request (interrupt) with its assigned SRPN.
The ICU arbitrates between all active SRNs, i.e. SRNs which have an active service request, wherein the arbitration is carried out based on the priorities of the active SRNs.
As soon as at least one SRN is requested on the interrupt bus (indicated via the interrupt bus), the ICU requests all active SRNs to transmit their priorities via the bus. The specific wiring of the interrupt bus causes the highest priority (priority of the winning SRN) to be put through to the ICU. The ICU returns the priority of the winning SRN to the SRNs. All SRNs taking part in the arbitration round compare the priority returned by the ICU with their own priority and reset themselves if they are identical. The ICU takes over the priority of the winning SRN and forwards it to the CPU.
FIG. 1 exemplarily shows arbitration bus signals between an ICU 110 and a plurality of SRNs 121, 122 and 123.
ICU 110 has a first output connected to a first SRN 121 via connections 170 and 171, a second SRN 122 via connections 170 and 172, and a third SRN 123 via connections 170 and 173. Connections 170, 171, 172 and 173 form the ICU command bus (icu_cmd) which indicates the status of the interrupt arbitration process.
ICU 110 has a second output connected to a first SRN 121 via connections 180 and 181, a second SRN 122 via connections 180 and 182, and a third SRN 123 via connections 180 and 183, wherein the connections 180, 181, 182 and 183 form the result bus (icu_result).
Each SRN comprises three outputs, wherein the first outputs of the SRNs 121, 122 and 123 are respectively connected to the inputs of a first OR gate 131a via connections 151a, 152a and 153a, the second outputs of the SRNs 121, 122 and 123 are respectively connected to the inputs of a second OR gate 131b via connections 151b, 152b and 153b, and the third outputs of the SRNs 121, 122 and 123 are respectively connected to the inputs of a third OR gate 131c via connections 151c, 152c and 153c. 
ICU 110 has a first input connected to the output of the first OR gate 131a via connection 160a, a second input connected to the output of the second OR gate 131b via connection 160b, and a third input connected to the output of the third OR gate 131c via connection 160c. 
An ICU may be configured in software to undertake, for example, 1, 2, 3 or 4 arbitration rounds. This allows arbitration between either 3, 15, 63 or 255 SRNs. Accordingly, each SRN that is active on an interrupt bus may have a service request priority number (SRPN) between 1 and either 3, 15,63 or 255 (inclusive) depending on the number of arbitration rounds the ICU is configured to perform. Suitably, inactive SRNs may have an SPRN of 0, whereas no active SRN should have an SRPN of 0.
Arbitration may be carried out by splitting the SRPN values of the SRNs into e.g. 1, 2, 3 or 4 pairs of bits. Starting with the most significant pair of bits used in the arbitration, every SRN with a pending service request sends the value of its pair of bits for this arbitration round to the ICU. It does this by asserting none or one of the or-tree signals (or_tree01, or_tree10, or_tree11) to the ICU. The or_tree signals from each SRN are or'ed together (at OR gates 131a, 131b, 131c) with the similar signals from all the other SRNs capable of connecting to the interrupt bus, as shown in FIG. 1.
The ICU determines the highest priority number being sent to it for this pair (e.g. 11, 10, 01 or 00), stores it, and sends the result back to all the SRNs on the result bus (icu_result). All participating SRNs compare the result bus to their pair of SRPN bits. If they are equal, then the SRN is the winner or equal winner of this round of arbitration. If so, the SRN remains ‘in’ the arbitration, and participates in the next round of arbitration (unless this is the final arbitration round). Otherwise the SRN has lost the arbitration to a higher priority interrupt, and they drop ‘out’ of this arbitration. At the end of the e.g. 1, 2, 3 or 4 rounds of arbitration, a single SRPN will have won.
Signals may take a long time to propagate through the ‘or_tree’, be decoded by the ICU, issued onto the result bus and clocked into the SRNs. This may take longer than a single ICU clock cycle in systems with a fast ICU clock rate. The ICU may therefore be configurable to allow more than one clock cycle per arbitration round.
In an interrupt system, interrupt requests from interrupt sources are transferred via an interrupt arbitration and, possibly, via further interrupt management, to interrupt targets, e.g. CPUs.
Many types of failures caused by soft errors may possibly occur on this path. Some of these are for example:                An inactive interrupt may erroneously be identified as active and transferred to the CPU.        An active or inactive interrupt may be distorted and processed as a different interrupt by the CPU.        The CPU may reset a wrong interrupt though having received the correct interrupt.        The winner of the interrupt arbitration may not possess the highest priority.        
International safety standards require to monitor interrupt systems in order to reach a so-called Safety Integrity Level (SIL). Known implementations of such monitoring requirements are based on application dependent schemes. Interrupt plausibility checks without hardware support are overly expensive and, in particular, reduce system performance. The level of checks required for this is normally much higher than actually required for the majority of typical interrupt service routines. Further, software solutions do not cover all types of errors and/or fault models. Software solutions are able to check whether an interrupt transferred to the CPU lies in an expected range. However, to check whether a certain interrupt is active at an interrupt source does not allow a definite conclusion as, in modern interrupt systems, the cause of an interrupt may already have been processed (and reset) by a previous call of the ISR.
Therefore, there e.g. exists a need for an apparatus and/or method providing application independent monitoring of interrupt systems that cover transient and permanent failures of interrupt busses and/or interrupt controllers.